home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-penners-mobileip-smip-00.txt < prev    next >
Encoding:
Text File  |  1993-10-01  |  33.9 KB  |  1,377 lines
  1.  
  2.  
  3.  
  4.  
  5.                                   - 1 -
  6.  
  7.  
  8.  
  9. Internet Engineering Task Force                             John Penners
  10. INTERNET DRAFT                            U S WEST Advanced Technologies
  11. draft-penners-mobileip-smip-00.txt                         Yakov Rekhter
  12.                                   T.J. Watson Research Center, IBM Corp.
  13.                                                           September 1993
  14.  
  15.  
  16.                         Simple Mobile IP (SMIP)
  17.  
  18.  
  19. Status of this Memo
  20.  
  21.  
  22.    This document is an Internet Draft.  Internet Drafts are working
  23.    documents of the Internet Engineering Task Force (IETF), its Areas,
  24.    and its Working Groups.  Note that other groups may also distribute
  25.    working documents as Internet Drafts.
  26.  
  27.    Internet Drafts are draft documents valid for a maximum of six
  28.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  29.    other documents at any time.  It is not appropriate to use Internet
  30.    Drafts as reference material or to cite them other than as a
  31.    ``working draft'' or ``work in progress.''
  32.  
  33.    Please check the 1id-abstracts.txt listing contained in the
  34.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  35.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  36.    current status of any Internet Draft.
  37.  
  38.    "This document has been presented to, and is being evaluated by, the
  39.    "Mobile IP" working group of the IETF.  This document is being 
  40.    published as an Internet Draft in order to allow the general IETF 
  41.    community the opportunity to gain a wider understanding of the issues
  42.    involved in mobile IP routing, as well as to understand the specific 
  43.    solution proposed in this document.  This document has not received 
  44.    any formal endorsement from the Mobile IP working group. 
  45.  
  46.  
  47. 1 Introduction
  48.  
  49.  
  50.    There have been several proposals for supporting mobility at the
  51.    network layer (e.g. [1], [2], [3], [4], [5]). While all these
  52.    proposals differ from each other in a number of features, all of them
  53.    also exhibit certain commonalities with each other. The proposal
  54.    described in this document is an attempt to extract and exploit this
  55.    commonality.  Its goal is to provide a simple, but solid foundation
  56.   
  57.  
  58.  
  59. Expiration Date March 1994                                      [Page 1]
  60.  
  61.  
  62.                            - 2 -
  63.  
  64.  
  65.    upon which additional optional features can be introduced in a
  66.    backward compatible fashion. The simplicity of the proposed scheme is
  67.    also expected to positively impact manageability and security aspects
  68.    associated with supporting mobility.
  69.  
  70.    It is our premise that the following factors will be key to
  71.    widespread usage:
  72.  
  73.  
  74.      1.  Adequate Security - Customers are not going to use Mobile-IP
  75.          (portable) if it does not provide adequate security protection.
  76.          These include masquarading as the mobile host, unwilling
  77.          disclosure of MH location, and potentially privacy.
  78.  
  79.  
  80.      2.  Ability to run traditional applications - It is not clear how
  81.          well existing transport protocols will deal with transients
  82.          introduced by mobility.  We also don't know many aspects
  83.          associated with mobility (e.g. its dynamics).  Therefore, it is
  84.          likely that some of the problems would not be discovered until
  85.          the actual deployment and usage.  Likewise, what may be
  86.          perceived as a problem today, may turned out to be a non-
  87.          problem in the operational environment.
  88.  
  89.  
  90.      3.  Manageability - The mobile system must be easy to manage or
  91.          system administrators won't want to deploy them.
  92.  
  93.  
  94.      4.  Rapid Wide Spread Deployment - Systems are more likely to be
  95.          deployed if there is already an established base.  This argues
  96.          for simple, easy to install and manage systems.
  97.  
  98.  
  99.      5.  Mobility - It is quite possible that most of the requirements
  100.          in today's environment can be satisfied with portability. In
  101.          the long term, on-line mobility may not be sufficient -- off-
  102.          line mobility may be required.  However, it is unlikely that
  103.          the off-line mobility can be solved at the network layer.
  104.  
  105.  
  106. 2 Elements
  107.  
  108.  
  109.    The scheme is described in terms of four components, Stationary Host
  110.    (SH), Mobile Host (MH), Home Register (MR), and Visiting Register
  111.    (VR).  The VR and HR could be colocated within a single physical
  112.    entity which may or may not have traditional router functionality.
  113.  
  114.  
  115.  
  116.  
  117. Expiration Date March 1994                                      [Page 2]
  118.  
  119.  
  120.                            - 3 -
  121.  
  122.  
  123.  
  124.        - Stationary Host (SH) : This is a host that may or may not be
  125.          stationary but is viewed as stationary.
  126.  
  127.  
  128.        - Home Register (HR) : This machine acts as an agent for the
  129.          Mobile Host.  It keeps track of its location and provide a
  130.          service that relays the incoming message to the Mobile Host.
  131.  
  132.  
  133.        - Visiting Register (VR) : This machine provides the Care-of
  134.          service for the Mobile Host.  It issues a c/o address to the
  135.          mobile host and receives message from the MH's HR and forwards
  136.          them to the MH.
  137.  
  138.  
  139.        - Mobile Host  (MH) : This is the mobile host.  It requires some
  140.          new protocols to handle it's mobility.  All communication to
  141.          this host (but not from this host) is through the Home Register
  142.          (HR) of the Mobile Host (MH).
  143.  
  144.  
  145.  
  146.  
  147. 3 Data and Control Flows
  148.  
  149.  
  150.    There are only three flows - two are data and one is a control
  151.  
  152.    The two data flows are as follows:
  153.  
  154.  
  155.      (1)  SH to MH => SH -> HR -> VR -> MH
  156.      (2)  MH to SH => MH -> VR -> SH
  157.  
  158.  
  159.    The proposal doesn't preclude future data traffic flow from SH to MH
  160.    that would bypass the HR.
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174. Expiration Date March 1994                                      [Page 3]
  175.  
  176.  
  177.                            - 4 -
  178.  
  179.  
  180.  
  181.    The only control flow which originates and terminates at the MH is as
  182.    follows:
  183.  
  184.            MH                         VR                            HR
  185.             |                          |                             |
  186.             |           MH Hello       |                             |
  187.             |------------------------->|    Location Update Request  |
  188.             |                          |---------------------------->|
  189.             |                          |                             |
  190.             |                          |   Location Update Confirm   |
  191.             |                          |<----------------------------|
  192.             |   VR Confirm             |                             |
  193.             |<-------------------------|                             |
  194.  
  195.  
  196.  
  197.    Since this model has four elements the following matrix can be used
  198.    to illustrate the information content that flow between elements.
  199.    This matrix contains both data and control flows.
  200.  
  201.  
  202.         \  Receiver
  203.          \    MH      VR      HR      SH  |
  204.    Sender |-------|-------|-------|-------|
  205.     MH    |   N/A |   1   |   2   |  3    |
  206.           |-------|-------|-------|-------|
  207.     VR    |   4   |   OP  |   5   |  OP   |
  208.           |-------|-------|-------|-------|
  209.     HR    |   6   |   7   |  N/A  |   8   |
  210.           |-------|-------|-------|-------|
  211.     SH    |   10  |   OP  |   9   |  N/A  |
  212.           |-------|-------|-------|-------|
  213.  
  214.  
  215.    OP - could be an option.  They increase the complexity of the
  216.    protocol and are not discussed in this proposal.
  217.  
  218.    VR -> VR could be used if there was handoff between VRs.  This could
  219.    create a security problem.
  220.  
  221.    N/A - Not applicable
  222.  
  223.    The content of new packets is indicated with [ ] below.  We assume
  224.    that the link layer will contain both the destination and source
  225.    physical addresses.
  226.  
  227.  
  228.  
  229.  
  230.  
  231. Expiration Date March 1994                                      [Page 4]
  232.  
  233.  
  234.                            - 5 -
  235.  
  236.  
  237.  
  238.    1) MH -> VR
  239.  
  240.  
  241.        - Notify VR and acquire c/o Address
  242.  
  243.        - Provide MH's permanent address to VR
  244.  
  245.        - Provide authentication for VR to pass to HR
  246.  
  247.    [ VR IP Addr, HR IP Addr, Sequence, MH/HR specific data (auth)]
  248.  
  249.  
  250.    MH/HR specific data and interpretation by the VR is not required. It
  251.    is likely to contain auth key and time stamp.
  252.  
  253.  
  254.    2)  MH -> HR This is an indirect flow of information (through the VR)
  255.  
  256.  
  257.        - Authentication and location info transmitted via VR
  258.  
  259.    Info contained in MH -> VR data packet
  260.  
  261.  
  262.    3)  MH -> SH
  263.  
  264.  
  265.        - Data via straight path (but flows through the VR serving the
  266.          MH)
  267.  
  268.    Info contained in normal IP packet
  269.  
  270.    4)  VR -> MH
  271.  
  272.        - Provide or refuse c/o on request
  273.  
  274.        - Forward received messages to MH
  275.  
  276.        - Notify MH of HR refusal to serve
  277.  
  278.    [MH addr, VR addr, Sequence, Attachment Accepted or Refused]
  279.  
  280.    5)  VR -> HR
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288. Expiration Date March 1994                                      [Page 5]
  289.  
  290.  
  291.                            - 6 -
  292.  
  293.  
  294.  
  295.        - Confirm MH location (possible after authentication)
  296.  
  297.        - Delivery Status (i.e. unable to deliver message)
  298.  
  299.        - Participate in tunnel Setup and teardown (detailed mgmt
  300.          provided by tunneling mechanism)
  301.  
  302.    [ HR IP Addr, VR IP Addr, MH IP Addr, Sequence, MH/HR specific data]
  303.  
  304.  
  305.    6)  HR -> MH
  306.  
  307.    This is an indirect flow (passes through VR)
  308.  
  309.  
  310.        - Forward Data packets
  311.  
  312.    Provided via HR -> VR
  313.  
  314.    7)  HR -> VR
  315.  
  316.  
  317.        - Tunnelled data
  318.  
  319.        - Participate in tunnel Setup and teardown (detailed mgmt
  320.          provided by tunneling mechanism)
  321.  
  322.    [ VR addr, HR addr, MH addr, Sequence, c/o address, Accepted or
  323.    Refused, HR/VR data]
  324.  
  325.    HR/VR data includes tunnel specific and service accept info that is
  326.    also used to generate VR -> MH packet
  327.  
  328.    8)  HR -> SH
  329.  
  330.  
  331.  
  332.        - Nothing special ( SH doesn't know the difference )
  333.  
  334.        - Ping responses on behalf of MH if MH is reachable (optional)
  335.  
  336.    9)  SH -> HR
  337.  
  338.        - Nothing special ( doesn't know the difference )
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345. Expiration Date March 1994                                      [Page 6]
  346.  
  347.  
  348.                            - 7 -
  349.  
  350.  
  351.  
  352.    10)  SH -> MH
  353.  
  354.        - Nothing special ( doesn't know the difference )
  355.  
  356.  
  357.  
  358. 4 Element Functions
  359.  
  360.  
  361.    The functions that each element must perform are indicated below.
  362.  
  363.    SH
  364.  
  365.        - Nothing new
  366.  
  367.    HR
  368.  
  369.        - Authenticate MH
  370.  
  371.        - Advertises direct network layer reachability for MHs associated
  372.          (served) with the HR
  373.  
  374.        - Encapsulate packets
  375.  
  376.        - Maintain location of MHs
  377.  
  378.        - Processes tunnel control messages generated by VR intended for
  379.          HR.  Normal tunnel control handled by tunnel protocol.
  380.  
  381.    MH
  382.  
  383.        - Request and receive c/o address
  384.  
  385.        - Provide authentication information to VR for HR
  386.  
  387.        - Provide permanent address to VR
  388.  
  389.        - Provide normal processing of data packets
  390.  
  391.    VR
  392.  
  393.        - Provide c/o address
  394.  
  395.        - Keep track of visiting MH
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402. Expiration Date March 1994                                      [Page 7]
  403.  
  404.  
  405.                            - 8 -
  406.  
  407.  
  408.  
  409.        - De-encapsulation of messages.
  410.  
  411.        - Provide error notification to the HR if necessary.
  412.  
  413.        - Return packets to HR after MH moved.
  414.  
  415.  
  416.  
  417. 5 Registration and Location Update
  418.  
  419.  
  420.  
  421.    Registration and Location Update is initiated by a MH (MH-controlled)
  422.    and is executed each time the MH wants to change its association with
  423.    VRs (acquire a new VR and dissolve an association with an old VR). It
  424.    is also executed periodically (timer driven) to refresh information.
  425.    The VR can refuse reregistration for local reasons such as over
  426.    utilization.
  427.  
  428.  
  429.    In this approach the VR informs the HR of the MH's location. The VR
  430.    can not register a MH without the MHs authentication information.
  431.    This is done indirectly through the VR.  In order to update the HR
  432.    the following must occur
  433.  
  434.      1.  The VR agrees to serve the MH
  435.  
  436.      2.  The HR agrees to that VR can serve MH
  437.  
  438.      3.  The HR agrees to serve MH
  439.  
  440.    Therefore the following sequences can occur:
  441.  
  442.    1st possible sequence:
  443.  
  444.        - MH sends a message to VR with MH-HR authentication info
  445.  
  446.        - VR informs MH of refusal to service MH
  447.  
  448.    Failure at 1).
  449.  
  450.    2nd possible sequence:
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459. Expiration Date March 1994                                      [Page 8]
  460.  
  461.  
  462.                            - 9 -
  463.  
  464.  
  465.  
  466.        - MH sends a message to VR with MH-HR authentication info
  467.  
  468.        - VR agrees to service MH
  469.  
  470.        - VR sends message to HR with MH authentication info
  471.  
  472.        - HR informs VR of refusal to use VR's service
  473.  
  474.        - VR informs MH of HR's refusal to use VR's service
  475.  
  476.    Failure at 2).
  477.  
  478.    3rd possible sequence:
  479.  
  480.        - MH sends a message to VR with MH-HR authentication info
  481.  
  482.        - VR agrees to service MH
  483.  
  484.        - VR sends message to HR with MH authentication info
  485.  
  486.        - HR informs VR of refusal to serve MH
  487.  
  488.        - VR informs MH of HRs refusal to serve MH
  489.  
  490.    Failure at 3).
  491.  
  492.    4th possible sequence:
  493.  
  494.        - MH sends a message to VR with MH-HR authentication info
  495.  
  496.        - VR agrees to service MH
  497.  
  498.        - VR sends message to HR with MH authentication info
  499.  
  500.        - HR informs VR of willingness to serve VR and MH
  501.  
  502.        - VR informs MH of willingness to serve
  503.  
  504.    Success.
  505.  
  506.    The Registration and Location Update protocol is implemented over
  507.    UDP.
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516. Expiration Date March 1994                                      [Page 9]
  517.  
  518.  
  519.                            - 10 -
  520.  
  521.  
  522.  
  523. 6 Tunneling
  524.  
  525.  
  526.    Tunneling mechanism could be the same as used elsewhere in the
  527.    Internet. (i.e. mbone) There are no special requirements for
  528.    tunnelling, so any tunnelling scheme will do the job but only one
  529.    scheme should be adopted.
  530.  
  531.  
  532. 7 Security
  533.  
  534.  
  535.    Privacy
  536.  
  537.  
  538.        - Privacy of data can be achieved by encryption at the
  539.          application level.
  540.  
  541.        - Privacy of location is ensure by routing through HR
  542.          Authentication
  543.  
  544.        - Authentication of the MH doesn't require trusting third
  545.          parties.  The only entities that have knowledge of the
  546.          authentication keys are the MH and it's HR.
  547.  
  548.  
  549.  
  550. 8 Draft of Management Information
  551.  
  552.  
  553.    Manageability
  554.  
  555.  
  556.        - Few elements - constrained elements should be easier to manage.
  557.  
  558.        - Well defined flows should allow easier tracking of information
  559.  
  560.        - Common tunneling mechanism should make management easier.
  561.  
  562.    Management Information Bases
  563.  
  564.    MH MIB
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573. Expiration Date March 1994                                     [Page 10]
  574.  
  575.  
  576.                            - 11 -
  577.  
  578.  
  579.  
  580.        - Available VR c/o addrs
  581.  
  582.        - Sequence of previous VRs c/o addrs
  583.  
  584.                 - Basis for termination
  585.  
  586.                 - Duration of attachment
  587.  
  588.        - VRs that refused service
  589.  
  590.                 - Basis for refusal
  591.  
  592.    VR MIB
  593.  
  594.  
  595.        - MHs being served
  596.  
  597.                 - Associated HRs
  598.  
  599.        - Sequence of MHs previously served
  600.  
  601.                 - Associated HRs
  602.  
  603.                 - Basis for termination
  604.  
  605.                 - Duration of attachment
  606.  
  607.        - MHs refused service
  608.  
  609.                 - Basis for refusal
  610.  
  611.        - List of MHs willing to serve (optional - default is all)
  612.  
  613.        - Statistics of packets returned to HR
  614.  
  615.    HR MIB
  616.  
  617.  
  618.        - VRs serving MH
  619.  
  620.                 - present VR
  621.  
  622.                 - previous VRs
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630. Expiration Date March 1994                                     [Page 11]
  631.  
  632.  
  633.                            - 12 -
  634.  
  635.  
  636.  
  637.        - Refused MHs
  638.  
  639.                 - authentication
  640.  
  641.                 - unacceptable VR
  642.  
  643.        - MH user profile
  644.  
  645.                 - entities that may know MH location
  646.  
  647.                 - Acceptable VRs
  648.  
  649.    SH MIB
  650.  
  651.  
  652.        - Nothing new
  653.  
  654.  
  655. 9 Pseudo-code for Colocated HR/VR
  656.  
  657.  
  658.  
  659.    The following pseudocode describes handling packets by a colocated
  660.    HR/VR. Suppression of packet looping due to transients or stale
  661.    information is always done at the HR. Looping is suppressed (by
  662.    dropping packet) only when the HR can't make any further progress (it
  663.    has the same COA as the previous one in the loop).
  664.  
  665.    VR in absence of the ability to deliver locally, sends packet to HR
  666.    associated with the destination address.
  667.  
  668.    The pseudo code uses the following abbreviations:
  669.  
  670.  
  671.        - encap-src-addr -- source address in the outer header
  672.  
  673.        - encap-dst-addr -- destination address in the outer header
  674.  
  675.        - src-addr -- source address in the inner header
  676.  
  677.        - dst-addr -- destination address in the inner header
  678.  
  679.        - COA(addr) returns Care of Address associated with addr
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687. Expiration Date March 1994                                     [Page 12]
  688.  
  689.  
  690.                            - 13 -
  691.  
  692.  
  693.  
  694.    if packet destined to HR/VR { /* acting as either VR or T-HR */
  695.      if encapsulation {  /* received data packet*/
  696.        strip encapsulation;
  697.        if local delivery possible  /* encapsulator has correct info */
  698.          do local delivery;
  699.        else {
  700.          swap(dst-addr, encap-dst-addr); /* send back to HR */
  701.          submit to normal forwarding;
  702.        }
  703.      }
  704.      else {  /* SMIP control packets follow this path  */
  705.        if packet is a SMIP control packet
  706.          perform_SMIP_processing(packet);
  707.        else
  708.          submit for normal local processing;
  709.      }
  710.    }
  711.    else {
  712.      if dst-addr != HR's client  /* acting as a router  */
  713.        submit to normal forwarding;
  714.      else {  /* acting as HR  */
  715.        if encapsulation { /* packet went at least once through HR */
  716.          swap(dst-addr, encap-dst-addr);
  717.          if COA(dst-addr) != NULL && COA(dst-addr) != encap-dst-addr {
  718.            encap-src-addr = encap-dst-addr = COA(dst-addr);
  719.            submit to normal forwarding;
  720.          }
  721.          else
  722.            discard the packet;
  723.        }
  724.        else {  /* packet came from the source, just re-address it */
  725.          if (COA(dst-addr) != NULL) {
  726.            encapsulate with encap-src-addr = encap-dst-addr = FA(dst-addr);
  727.            submit to normal forwarding;
  728.          }
  729.          else { /* no forwarding information available */
  730.            if local subnet delivery is possible
  731.              submit to normal forwarding;
  732.            else
  733.              discard the packet;
  734.         }
  735.        }
  736.      }
  737.    }
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744. Expiration Date March 1994                                     [Page 13]
  745.  
  746.  
  747.                            - 14 -
  748.  
  749.  
  750.  
  751.    /*
  752.     * The following pseudo code describe processing of SMIP control
  753.     * packets by VR/HR
  754.     */
  755.  
  756.    perform_SMIP_processing(packet)
  757.    {
  758.    if MH Hello packet {
  759.      if VR or T-HR capable
  760.        if MH already registered
  761.          if MH IP addr already register
  762.             if  LinkLayer (registered MH IP addr) = LinkLayer (new  MH IP addr)
  763.               if acting as T-HR for MH
  764.                  if MH authenticates
  765.                    convert to VR confirm
  766.                       set confirm bit
  767.                       dst addr =  MH addr
  768.                       src addr = T-HR addr
  769.                       submit to normal forwarding
  770.                  else /* failed auth at T-HR */
  771.                    covert to VR confirm /* confirmation refuse */
  772.                       clear confirm bit
  773.                       dst addr =  MH addr
  774.                       src addr = T-HR addr
  775.                       submit to normal forwarding
  776.                       note MH addr and failed authentication
  777.               else /* acting as VR for MH */
  778.                  convert MH Hello into Location Update
  779.                      dst addr =  HR addr
  780.                      src addr = VR addr
  781.                      submit to normal forwarding
  782.             else /* Different Link Layer Address for MH IP addr /*
  783.                note as security suspicious
  784.        else  /* MH not registered */
  785.          temporarily register MH (MH addr, HR addr, Sequence)
  786.          convert MH Hello into Location Update
  787.                   dst addr =  HR addr
  788.                   src addr = VR addr
  789.                   submit to normal forwarding
  790.      else  /* Not VR so should not receive MH Hello packet */
  791.         drop packet /* Not beaconing so no need to send error message */
  792.    }
  793.    else {
  794.      if Loc Update Req packet
  795.        if acting as a HR or T-HR
  796.  
  797.  
  798.  
  799.  
  800.  
  801. Expiration Date March 1994                                     [Page 14]
  802.  
  803.  
  804.                            - 15 -
  805.  
  806.  
  807.  
  808.          if MH authenticates
  809.             convert Loc Update Req to Loc Update Confirm
  810.               auth key = MH public key
  811.               set confirm bit
  812.               dst addr = VR addr
  813.               src addr = HR add
  814.            submit to normal forwarding
  815.            register MH at VR
  816.          else
  817.            convert Loc Update Req to Loc Update Confirm
  818.               clear confirm bit
  819.               dst addr =  HR addr
  820.               src addr = VR addr
  821.               submit to normal forwarding
  822.               note MH addr and failed authentication
  823.        else
  824.           drop packet /* Not an HR */
  825.  
  826.      else {
  827.        if Loc Update Conf packet
  828.          if confirm bit set
  829.            convert Loc Update Conf to VR confirm
  830.               dst addr =  MH addr
  831.               src addr =  VR addr
  832.            submit to normal forwarding
  833.            convert temp registration to permenant registration
  834.            save public authentication key
  835.          else /* authentication failed */
  836.            convert Loc Update Conf to VR confirm
  837.               dst addr =  MH addr
  838.               src addr =  VR addr
  839.            submit to normal forwarding
  840.            eliminate temp registration
  841.            make note of failed authentication
  842.        else /* not a VR */
  843.           drop packet
  844.         }
  845.      }
  846.    }
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858. Expiration Date March 1994                                     [Page 15]
  859.  
  860.  
  861.                            - 16 -
  862.  
  863.  
  864.  
  865. 10 Acknowledgment
  866.  
  867.  
  868.    We would like to express our thanks to Kannan Alagappan (DEC), and
  869.    Steve Deering (XEROX) for their review and constructive comments.
  870.  
  871.  
  872.  
  873.  
  874. Appendix A
  875.  
  876.  
  877.  
  878. A.1 Future Enhancements and Associated Issues
  879.  
  880.  
  881.    We describe possible enhancements that can be added to the base
  882.    proposal. The enhancements can be added in an incremental fashion.
  883.  
  884.  
  885. A.1.1 Cascading of Systems
  886.  
  887.  
  888.    In order to cascade systems a VR needs to have some HR functionality.
  889.    As indicated earlier a VR and HR can be colocated.  A VR functioning
  890.    similar to HR is called a T-HR.  A T-HR is slightly different than a
  891.    HR.  For example, unlike the HR, a T-HR does not advertise direct
  892.    network layer reachability to MHs served by the T-HR.
  893.  
  894.    The following sequence of events illustrate how cascading can occur
  895.  
  896.  
  897.        - The MH request VR service
  898.  
  899.        - The VR with T-HR capability provides the HR with the standard
  900.          information and informs the HR of it's T-HR capability.
  901.  
  902.        - The HR agrees to allow the VR to serve the MH and also passed a
  903.          public authentication key to the VR.
  904.  
  905.        - The VR lets the MH know that the attachment is successful and
  906.          the VR is T-HR capable.
  907.  
  908.        - When the MH moves to a new VR it tells the new VR of the T-HR
  909.          location and passes an authentication key that the T-HR uses to
  910.  
  911.  
  912.  
  913.  
  914.  
  915. Expiration Date March 1994                                     [Page 16]
  916.  
  917.  
  918.                            - 17 -
  919.  
  920.  
  921.  
  922.          authenticate it.  As a fall-back position the new VR can always
  923.          go to the HR.
  924.  
  925.        - The T-HR agrees to serve as the HR and the new VR acts as if
  926.          were part of the baseline system.
  927.  
  928.    This would result in the following new data flow:
  929.  
  930.      SH==>MH: SH->HR->T-HR->VR->MH
  931.  
  932.  
  933.    PSEUDO CODE FOR CASCADING OF SYSTEMS IN COLOCATED HR/VR
  934.  
  935.  
  936.    if packet destined to HR/VR { /* acting as either VR or T-HR */
  937.      if encapsulation {  /* received data packet*/
  938.        strip encapsulation;
  939.        if local delivery possible  /* encapsulator has correct info */
  940.          do local delivery;
  941.        else { /* packet already traversed through HR */
  942.          /*
  943.           * Acting as T-HR and have non-null COA
  944.           */
  945.           if HR/VR is T-HR capable && dst-addr == T-HR's client && COA(dst-addr) 
  946. != NULL {
  947.            encap-dst-addr = COA(dst-addr);
  948.             submit to normal forwarding;
  949.          }
  950.          else { /* encapsulator has stale info, send to HR */
  951.            if encap-src-addr != encap-dst-addr { /* packet came from T-HR */
  952.              swap(encap-src-addr, encap-dst-addr);
  953.            }
  954.            swap(dst-addr, encap-dst-addr); /* send back to HR */
  955.            submit to normal forwarding;
  956.          }
  957.        }
  958.      }
  959.      else {  /* SMIP control packets follow this path  */
  960.        if packet is a SMIP control packet
  961.          perform SMIP processing;
  962.        else
  963.          submit for normal local processing;
  964.      }
  965.    }
  966.    else {
  967.      if dst-addr != HR's client  /* acting as a router  */
  968.  
  969.  
  970.  
  971.  
  972.  
  973. Expiration Date March 1994                                     [Page 17]
  974.  
  975.  
  976.                            - 18 -
  977.  
  978.  
  979.  
  980.        submit to normal forwarding;
  981.      else {  /* acting as HR  */
  982.        if encapsulation { /* packet went at least once through HR */
  983.          swap(dst-addr, encap-dst-addr);
  984.          if COA(dst-addr) != NULL && COA(dst-addr) != encap-dst-addr {
  985.            send Location Update information to src-addr;
  986.            encap-src-addr = encap-dst-addr = COA(dst-addr);
  987.            submit to normal forwarding;
  988.          }
  989.          else {
  990.            if COA(dst-addr) == encap-dst-addr
  991.              mark COA(dst-addr) as "suspicious";
  992.            discard the packet;
  993.        }
  994.        else {  /* packet came from the source, just re-address it */
  995.          if (COA(dst-addr) != NULL) {
  996.            send Location Update information to src-addr;
  997.            encapsulate with encap-src-addr = encap-dst-addr = COA(dst-addr);
  998.            submit to normal forwarding;
  999.          }
  1000.          else { /* no forwarding information available */
  1001.            if local subnet delivery is possible
  1002.              submit to normal forwarding;
  1003.            else
  1004.              discard the packet;
  1005.          }
  1006.        }
  1007.      }
  1008.    }
  1009.  
  1010.  
  1011.  
  1012. A.1.2 Elimination of Triangular Routing
  1013.  
  1014.  
  1015.  
  1016.    The elimination of Triangular Routing creates a security problem
  1017.    without an infrastructure that provides a trusted third party to
  1018.    handle the processing of authentication keys.
  1019.  
  1020.    Triangular routing may not be as big a problem as some think.
  1021.    Triangular routing is relatively efficient in the following cases
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030. Expiration Date March 1994                                     [Page 18]
  1031.  
  1032.  
  1033.                            - 19 -
  1034.  
  1035.  
  1036.  
  1037.        - The SH is close to the HR while MH is not.
  1038.  
  1039.        - The MH is close to the HR while SH is not
  1040.  
  1041.        - The HR is between the SH and the MH.
  1042.  
  1043.    Both the first and the second cases may be reasonable assumptions
  1044.    while the third case is random.
  1045.  
  1046.    Possible solution:
  1047.  
  1048.  
  1049.        - Allow MH and/or HR to send Location Update Request messages to
  1050.          MH's peer.
  1051.  
  1052.  
  1053.    COLOCATED HR/VR PSEUDO CODE FOR ELIMINATING TRIANGULAR ROUTING
  1054.    WITHOUT CASCADING
  1055.  
  1056.  
  1057.  
  1058.    if packet destined to HR/VR { /* acting as either VR */
  1059.      if encapsulation {  /* received data packet*/
  1060.        strip encapsulation;
  1061.        if local delivery possible  /* encapsulator has correct info */
  1062.          do local delivery;
  1063.        else {
  1064.          swap(dst-addr, encap-dst-addr);
  1065.          submit to normal forwarding;
  1066.        }
  1067.      }
  1068.      else {  /* SMIP control packets follow this path  */
  1069.        if packet is a SMIP control packet
  1070.          perform SMIP processing;
  1071.        else
  1072.          submit for normal local processing;
  1073.      }
  1074.    }
  1075.    else {
  1076.      if dst-addr != HR's client  /* acting as a router  */
  1077.        submit to normal forwarding;
  1078.      else {  /* acting as HR  */
  1079.        if encapsulation {
  1080.          swap(dst-addr, encap-dst-addr);
  1081.          if encap-src-addr == src-addr { /* packet didn't traverse through HR */
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087. Expiration Date March 1994                                     [Page 19]
  1088.  
  1089.  
  1090.                            - 20 -
  1091.  
  1092.  
  1093.  
  1094.            if encap-dst-addr == FA(dst-addr) {/* HR may have stale information */
  1095.              mark FA(dst-addr) as "suspicious";
  1096.              discard the packet;
  1097.            }
  1098.            else { /* src has stale info */
  1099.              if FA(dst-addr) != NULL {
  1100.                send Location Update information to src-addr;
  1101.                encap-src-addr = encap-dst-addr = FA(dst-addr);
  1102.                submit to normal forwarding;
  1103.              }
  1104.              else
  1105.                discard the packet;
  1106.            }
  1107.          }
  1108.          else { /* packet went at least once through HR */
  1109.            if FA(dst-addr) != NULL && FA(dst-addr) != encap-dst-addr {
  1110.              send Location Update information to src-addr;
  1111.              encap-src-addr = encap-dst-addr = FA(dst-addr);
  1112.              submit to normal forwarding;
  1113.            }
  1114.            else {
  1115.              if FA(dst-addr) == encap-dst-addr
  1116.                mark FA(dst-addr) as "suspicious";
  1117.              discard the packet;
  1118.            }
  1119.          }
  1120.        }
  1121.        else {  /* packet came from the source, just re-address it */
  1122.          if (FA(dst-addr) != NULL) {
  1123.            send Location Update information to src-addr;
  1124.            encapsulate with encap-src-addr = encap-dst-addr = FA(dst-addr);
  1125.            submit to normal forwarding;
  1126.          }
  1127.          else { /* no forwarding information available */
  1128.            if local subnet delivery is possible
  1129.              submit to normal forwarding;
  1130.            else
  1131.              discard the packet;
  1132.          }
  1133.        }
  1134.      }
  1135.    }
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144. Expiration Date March 1994                                     [Page 20]
  1145.  
  1146.  
  1147.                            - 21 -
  1148.  
  1149.  
  1150.  
  1151. A.1.3 Combined Elimination of Triangular Routing and Cascading of
  1152. Systems
  1153.  
  1154.  
  1155.  
  1156.    PSEUDO CODE FOR ELIMINATION OF TRIANGULAR ROUTING AND CASCADING OF
  1157.    SYSTEMS IN COLOCATED HR/VR
  1158.  
  1159.  
  1160.    if packet destined to HR/VR { /* acting as either VR or T-HR */
  1161.      if encapsulation {  /* received data packet*/
  1162.        strip encapsulation;
  1163.        if local delivery possible  /* encapsulator has correct info */
  1164.          do local delivery;
  1165.        else {
  1166.          if encap-src-addr == src-addr { /* packet didn't traverse through HR */
  1167.            /*
  1168.             * Acting as T-HR and have non-null FA
  1169.             */
  1170.            if HR/VR is T-HR capable && dst-addr == T-HR's client && FA(dst-addr) 
  1171. != NULL {
  1172.              encap-dst-addr = FA(dst-addr);
  1173.              submit to normal forwarding;
  1174.            }
  1175.            else { /* encasulator has stale info, send to HR */
  1176.              swap(dst-addr, encap-dst-addr);
  1177.              submit to normal forwarding;
  1178.            }
  1179.          }
  1180.          else { /* packet already traversed through HR */
  1181.            /*
  1182.             * Acting as T-HR and have non-null FA
  1183.             */
  1184.            if HR/VR is T-HR capable && dst-addr == T-HR's client && FA(dst-addr) 
  1185. != NULL {
  1186.              encap-dst-addr = FA(dst-addr);
  1187.              submit to normal forwarding;
  1188.            }
  1189.            else { /* encasulator has stale info, send to HR */
  1190.              if encap-src-addr != encap-dst-addr { /* packet came from T-HR */
  1191.                swap(encap-src-addr, encap-dst-addr);
  1192.              }
  1193.              swap(dst-addr, encap-dst-addr); /* send back to HR */
  1194.              submit to normal forwarding;
  1195.            }
  1196.          }
  1197.        }
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203. Expiration Date March 1994                                     [Page 21]
  1204.  
  1205.  
  1206.                            - 22 -
  1207.  
  1208.  
  1209.  
  1210.      }
  1211.      else {  /* SMIP control packets follow this path  */
  1212.        if packet is a SMIP control packet
  1213.          perform SMIP processing;
  1214.        else
  1215.          submit for normal local processing;
  1216.      }
  1217.    }
  1218.    else {
  1219.      if dst-addr != HR's client  /* acting as a router  */
  1220.        submit to normal forwarding;
  1221.      else {  /* acting as HR  */
  1222.        if encapsulation {
  1223.          swap(dst-addr, encap-dst-addr);
  1224.          if encap-src-addr == src-addr { /* packet didn't traverse through HR */
  1225.            if encap-dst-addr == FA(dst-addr) {/* HR may have stale information */
  1226.              mark FA(dst-addr) as "suspicious";
  1227.              discard the packet;
  1228.            }
  1229.            else { /* src has stale info */
  1230.              if FA(dst-addr) != NULL {
  1231.                send Location Update information to src-addr;
  1232.                encap-src-addr = encap-dst-addr = FA(dst-addr);
  1233.                submit to normal forwarding;
  1234.              }
  1235.              else
  1236.                discard the packet;
  1237.            }
  1238.          }
  1239.          else { /* packet went at least once through HR */
  1240.            if FA(dst-addr) != NULL && FA(dst-addr) != encap-dst-addr {
  1241.              send Location Update information to src-addr;
  1242.              encap-src-addr = encap-dst-addr = FA(dst-addr);
  1243.              submit to normal forwarding;
  1244.            }
  1245.            else
  1246.              if FA(dst-addr) == encap-dst-addr
  1247.                mark FA(dst-addr) as "suspicious";
  1248.              discard the packet;
  1249.          }
  1250.        }
  1251.        else {  /* packet came from the source, just re-address it */
  1252.          if (FA(dst-addr) != NULL) {
  1253.            send Location Update information to src-addr;
  1254.            encapsulate with encap-src-addr = encap-dst-addr = FA(dst-addr);
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260. Expiration Date March 1994                                     [Page 22]
  1261.  
  1262.  
  1263.                            - 23 -
  1264.  
  1265.  
  1266.  
  1267.            submit to normal forwarding;
  1268.          }
  1269.          else { /* no forwarding information available */
  1270.            if local subnet delivery is possible
  1271.              submit to normal forwarding;
  1272.            else
  1273.              discard the packet;
  1274.          }
  1275.        }
  1276.      }
  1277.    }
  1278.  
  1279.  
  1280.  
  1281. A.1.4 Multicasting
  1282.  
  1283.  
  1284.    The HR or a T-HR can be used to aid in multicasting of packets to and
  1285.    from the MH.
  1286.  
  1287.  
  1288. A.1.5 Off-line Mobility
  1289.  
  1290.  
  1291.    Off-line Mobility is an important problem that is unlikely to be
  1292.    solved at the network layer alone.
  1293.  
  1294.  
  1295. References
  1296.  
  1297.  
  1298.    [1] Carlberg, K., "A Routing Architecture That Supports Mobile End
  1299.    Systems", Proceedings of IEEE MILCOM, October 1992
  1300.  
  1301.    [2] Cohen, D., Postel, J., Rom, R., "IP Addressing and Routing in a
  1302.    Local Wireless Network", INFOCOM 1992, pp. 5A.3.1--5A.3.7
  1303.  
  1304.    [3] John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr.  "IP-Based
  1305.    protocols for mobile internetworking", Proceedings of SIGCOMM'91,
  1306.    ACM, September, 1991, pp. 235--245.
  1307.  
  1308.    [4] Fumio Teraoka, Yasuhiko Yokote, and Mario Tokoro, "A Network
  1309.    Architecture Providing Host Migration Transparency", Proceedings of
  1310.    SIGCOMM'91, ACM, September, 1991, pp. 209-220
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317. Expiration Date March 1994                                     [Page 23]
  1318.  
  1319.  
  1320.                            - 24 -
  1321.  
  1322.  
  1323.  
  1324.    [5] Hiromi Wada, Tatsuya Ohnishi, and Brian Marsh, "Packet Forwarding
  1325.    for Mobile Hosts", work in progress
  1326.  
  1327.  
  1328. Security Considerations
  1329.  
  1330.    Security issues are not discussed in this memo.
  1331.  
  1332.  
  1333. Authors' Addresses
  1334.  
  1335.  
  1336.    John Penners
  1337.    U S WEST Advanced Technologies
  1338.    4001 Discovery Drive
  1339.    Boulder, CO 80303
  1340.    Phone:(303) 541-6106
  1341.    email: jpenners@atqm.advtech.uswest.com
  1342.  
  1343.    Yakov Rekhter
  1344.    T.J. Watson Research Center IBM Corporation
  1345.    P.O. Box 218
  1346.    Yorktown Heights, NY 10598
  1347.    Phone:  (914) 945-3896
  1348.    email:  yakov@watson.ibm.com
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374. Expiration Date March 1994                                     [Page 24]
  1375.  
  1376.  
  1377.